SOA is the abbreviation of “service-oriented architecture” and indicates that an application can be composed of a set of independent and mutually cooperative sub-systems or services. Such an architecture makes every service independent and only informs other services of the interface necessary to be declared. The SOA not only enables system constructors to organize and decrease dependency relations in their designed products, but also provides a trimmed service suite in a developing environment. This method can be used to support the existing requirements, e.g., the enterprise application assembly, and to provide a base for platform extension so as to meet special commercial needs, e.g., the quick customization of E-commerce-related solutions.
As a basic delivery form of the SOA, web services are widely used day by day. The so-called web services are online application services published by an enterprise for satisfying its special commercial needs, and these online services can be accessed and utilized by applications of other companies and cooperative partners via networks (including the Internet, enterprise internal networks, and enterprise external networks, etc.). The web services, as an effective mechanism of flow integration in an enterprise, are utilized in commerce, Nasdaq and Australia Stock Exchange System and so on are well-known examples that use the web services. In fact, the web services can perform any function from a simple request to a complicated commercial transaction.
Any SOA or web service comprises three roles: a service requester (or called a service consumer), a service provider and a service registry, as shown in FIG. 1. The architecture 100 shown in FIG. 1 comprises a service requester 110, a service provider 120 and a service registry 130.
Among these, the service provider 120 is responsible for building a useful service and establishing a service metadata therefor, and then publishes the metadata to one or more service registries 130, so that the service requester queries service metadata from the one or more service registries 130. The metadata may comprise functional description and non-functional description, policies, and relevant data, etc of the services.
The service registry 130 is a metadata repository for services that participate in an SOA and is responsible for maintaining and promulgating service metadata published thereon by the service provider 120, and allows the service requester 110 to perform query in a service description owned by a local service registry 130. In the prior-art SOA, it is not necessary for the service registry 130 to participate in an interacting process between the service requester and the service provider.
In addition, between the service requester 110 and the service provider 120, some intermediators such as a gateway, an enterprise service bus (EBS) and so on (not shown) may further be provided. These intermediators have a simple request-response delivery function between the service requester 110 and the service provider 120.
FIG. 1 further shows the SOA contains three operations among the service requester 110, the service provider 120 and the service registry 130: publish, find and bind, and these operations define a contract among the respective roles of the SOA.
To date, in the SOA or the web service system as described above, the service registry can only employ the Universal Description Discovery & Integration (UDDI) standard. All the vendors of the service registries (such as IBM®, Microsoft®, SUN®, BEA®, Systinet®, etc.) support UDDI 3.0 in their products. UDDI is a standard defined by OASIS and its focus is the definition of a set of services supporting the description and discovery of
1) businesses, organizations, and other web service providers;
2) the web services that are available; and
3) the technical interface which may be used to access the web services.
Based on a common set of industry standards, UDDI provides a foundational infrastructure for web services based computing environment. However, the use of UDDI standard result in technical limitations of the SOA or web services in terms of service control and sharing, etc. On one hand, as to the control and management of service metadata, using the UDDI standard has the following disadvantages:
1) Lack of extensible data model and methods for query—The fixed format of service metadata could not meet the need to add more features or service specific properties;
2) Lack of service lifecycle management;
3) Lack of runtime control during service invocation—This is because in the existing SOA triangular architecture, a service registry only plays its role in a static configuration process of services, but does not participate in a dynamic interacting process between a service requester and a service provider (including the gateway or EBS, etc.) during service runtime; and
4) Lack of mechanism for functionality extension.
On the other hand, with the wide use of web services at present, the number of services become large with advent of more and more fined services that are compliant with different standards (such as WSRP, uPnP, etc.). Thus, the number of service registries increases rapidly as well. In this situation, sharing information among associated UDDI registries become the urgent requirement to promote web service technologies.
According to the stipulation of Version 3 of UDDI specification, sharing information among UDDI registries is implemented by replicating service metadata, that is, an importer gets all the metadata of UDDI entities from source registries and then replicates said metadata into target registries. The importer here is a publisher who reads data via the Inquiry or Subscription API from one or more source registries and publishes it to a target registry. For detailed information for sharing information in UDDI, please refer to “UDDI Version 3.0.2, UDDI Spec Technical Committee Draft, Dated 20041019”. The mechanism for implementing service sharing among the UDDI registries by replication has the following disadvantages:
1) The topology of UDDI registries is different from that of the internet domain, so it is hard to manipulate service information in every internet autonomous system.
2) As the number of registries and UDDI entities becomes large, there is hardly enough storage space to replicate all the metadata of all the entities in one registry.
3) When information sharing is implemented by replication of entities, there lacks a mechanism to synchronize duplicates of the same entity registered in different registries.
4) Since not all the shared UDDI entities could be replicated in one UDDI registry, a UDDI client must query several UDDI registries to search for the target UDDI entity.
5) As the quantity of registries becomes large and there is no centralized location information of UDDI registries, it is difficult for the client to find and travel through all the accessible registries (especially for the client with limited computing power and communication bandwidth).
In view of the above cases, it is necessary to improve the service registries of the SOA or web services so as to enhance flexibility and operability with respect to management and sharing service.